As used herein, an electronic communication (“EC”) is considered to be any communication in electronic form. ECs have become an integral part of transacting business today, especially with the growth of the Internet and e-commerce. An EC can represent, for example, a request for access to information or a physical area, a financial transaction, such as an instruction to a bank to transfer funds, or a legal action, such as the delivery of an executed contract.
In order for ECs to be effective, a recipient of the EC must be able to associate reliably the EC with the entity sending the EC or on whose behalf the EC is sent (collectively referred to herein as “sender”). A recipient receiving an EC requesting access to information or a physical area, prior to granting such information, needs to know who is requesting the access to verify that access may be given. Similarly, a recipient such as a financial institution receiving an EC instructing it to transfer funds from an account of one of its customers needs to know who is requesting the transaction to verify that the sender is authorized to make the transaction on the account.
In order to identify reliably the sender of an EC, an entity first must identify itself in some manner to the recipient some time before sending the EC, in response to which the recipient must assign an entity identifier to the entity. Thereafter, the entity identifier is included in an EC. Upon receipt of the EC, the recipient then cross-references the entity identifier included therein with the assigned entity identifier to identify thereby the sender of the EC. As used herein, “Entity Authentication” refers to the act of checking an entity identifier provided by a suspect entity against a previously assigned entity identifier in order to identify reliably the suspect entity.
Three common types of Entity Authentication are utilized today. A first type is based on what an entity “has,” in that possession of an object serves as the entity identifier (herein referred to as “Factor A Entity Authentication”). An example of the use of Factor A Entity Authentication includes the presentation of a credit card at a “pay-at-the-pump” gas station, wherein sliding of the card within a magnetic card reader provides a credit account number, which is magnetically stored on the credit card, to the card reader. The account number then is transmitted in an EC to a third-party authorization service for comparison with credit account numbers. In a simple case, if the account number transmitted by the card reader matches a valid account number in the database of the authorization service, if the account has not exceeded its credit limit, and if the card has not been reported lost or stolen, then the authorization for the charge may be granted. In this example, the entity of the EC (i.e., the consumer at the gas pump) is identified by the account number previously assigned by a financial institution to the consumer.
A second type of Entity Authentication is based on what an entity “knows,” in that disclosure of particular information associated with the entity serves as the entity identifier (herein referred to as “Factor B Entity Authentication”). An example of the use of Factor B Entity Authentication includes a request by an entity for information regarding a credit card account, such as balance information over the telephone. In this example, before the financial institution at which the credit card account is maintained provides the account balance to the caller, the caller's identity is verified by requiring the caller to provide the account number and some other cardholder specific information, such as the zip code for the cardholder or the last four digits of the cardholder's social security number—information which does not appear on the face of the card itself. If the information transmitted in the EC over the telephone matches the information associated with the credit card account, as maintained by the financial institution, then the caller is authenticated and the account balance is provided. In this case, the entity of the EC (i.e., the caller) is identified by the account number previously assigned and the cardholder-specific information previously obtained by the financial institution.
A third type of Entity Authentication is based on what an entity “is,” in that a biometric characteristic—such as a fingerprint—of an entity serves as the entity identifier (herein referred to as “Factor C Entity Authentication”). While not including an EC, an example of the use of Factor C Entity Authentication includes a customer physically presenting a credit card for payment to a merchant and providing a handwritten signature on the charge slip. In this scenario, the merchant obtains and compares the signature on the charge slip signed by the customer against the signature of the cardholder appearing on the back of the credit card. This comparison is made particularly in cases where the credit account number is not verified through an authorization service as described above, or where the purchase is for a large amount. Upon a successful comparison as determined by the merchant, the customer is authenticated as the cardholder and the merchant accepts the charge slip as payment. Factor C Entity Authentication has yet to be widely utilized with respect to ECs and is most often found in high security scenarios in which a biometric characteristic, such as a fingerprint or retina scan of an individual, is required for authentication of the individual. When used with ECs, a value for the biometric characteristics is obtained with a sensor or other electronic apparatus and the biometric value is compared (using fuzzy logic) with a prestored biometric value for the same biometric characteristic in determining whether there is a match.
For additional security, multiple provision of the same type of Entity Authentication is sometimes required. For example, requiring two forms of personal identification involves two different pieces of Factor A Entity Authentication information. Knowing and providing two different “shared-secrets,” such as a zip code and mother's maiden name, involves two different pieces of Factor B Entity Authentication information. Providing two different biometric samples, such as a handwritten signature and a thumbprint, involves two different pieces of Factor C Entity Authentication information. Additional security can also be achieved by requiring the combination of two of more different types of Entity Authentication. For example, Factors A and B Entity Authentication are required in ATM transactions, in which possession of an ATM card and knowledge of the corresponding PIN are required for use.
It will be appreciated and well known by those having ordinary skill in the art that the trust associated with conventional authentication systems is relatively weak, in that the entity identifier utilized for verifying entities today is easily susceptible to misappropriation or forgery. For example, credit cards can readily be counterfeited. Further, an account number, account-specific information, and customer-specific information—including biometric values—all are susceptible to discovery (such as during transmission for authentication) and then fraudulent use in later authentications for transactions upon the relevant account. Once such information is misappropriated, it is difficult for a recipient of an EC to determine that the EC, including an entity identifier, has been sent fraudulently. Moreover, because of the weakness of Entity Authentication in ECs, business methods and systems including ECs are subject to higher risks and less trust than would otherwise be the case if the Entity Authentication were stronger.
In an attempt to increase the trust in business methods and systems utilizing Entity Authentication in ECs, encryption technology has been used to attempt to “hide” or otherwise prevent entity identifier information from being intercepted during communications and transmissions. Digital signatures have also been incorporated into the existing business infrastructure as an attempted means of providing strong authentication, in that an EC sents with an attached digital signature is presumed to come from the entity that claims to have digitally signed the message contained in the EC. In particular, a digital certificate now is used to establish the identity of an entity for which an EC is sent that includes a digital signature originated specifically for a particular message of the EC.
In this regard, the origination of a digital signature generally comprises: (1) the calculation of a message digest-such as a hash value; and (2) the subsequent encryption of the message digest. The message digest is encrypted by an electronic device generally using a private key of a key pair used in public-private key cryptography (also known as asymmetric cryptography). The resulting ciphertext itself usually constitutes the digital signature, which typically is appended to the message to form the EC. The second part of originating the digital signature—using encryption with a private key—is referred to herein as “generating” the digital signature, and the combined two steps is referred to herein as “originating” the digital signature. Furthermore, while the generation of the digital signature is conventionally understood as the encryption of the message digest, it is contemplated herein that generating the digital signature also may include simply encrypting the message rather than the message digest. Digital signatures are important because any change whatsoever to the message in an EC is detectable from an analysis of the message and the digital signature. In this context, the digital signature is used to “authenticate” a message contained within the EC (hereinafter referred to as “Message Authentication”). Message authentication verifies the integrity of the message and should not be confused with Entity Authentication, which verifies an identity of an entity as represented by an entity identifier.
In an example of Message Authentication, a message digest is calculated by applying a hashing algorithm—such as the SHA-1 algorithm—to data representing the message. The hashing algorithm may be applied either within the device or external to the device with the resulting hash value then being transmitted to the device for generation of the digital signature. In order to perform Message Authentication in this example, the recipient of the EC must know or be able to obtain both the identity of the hashing algorithm applied to the message as well as the public key (“PuK”) corresponding to the private key used to encrypt the message digest. With this knowledge, the recipient applies the appropriate hashing algorithm to the message to calculate a hash value, and the recipient decrypts the digital signature using the public key. If the hash value calculated by the recipient equals the hash value of the decrypted digital signature, then the recipient determines that the content of the message contained in the EC was not altered in transmission, which necessarily would have changed the hash value.
Although message authentication should not be confused with Entity Authentication, the process of performing Message Authentication simultaneously enables the recipient of an EC to authenticate the sender of the EC, in so much as the recipient thereby confirms that the sender of the EC possessed the private key corresponding to the public key used successfully to authenticate the message. This inherently represents Factor A Entity Authentication regarding the EC. Factor A Entity Authentication is useful when the recipient of the EC has trusted information regarding the identity of the owner of the private key.
This trusted information conventionally is provided based on a digital certificate issued by a trusted third party that accompanies the digital signature and that binds the identity of the private key owner with the public key. A digital certificate (also known as a “digital ID”) comprises a voucher by a third-party (commonly referred to as a “Certification Authority”) certifying the identity (or other attributes) of an owner of a public key. Essentially, a digital certificate is the electronic counterpart to a driver license, passport, membership card, and other paper-based forms of identification. The digital certificate itself comprises an electronic message including a public key and the identity of the owner of the public key. A digital certificate also typically contains an expiration date for the public key, the name of the Certification Authority, a serial number of the digital certificate, and a digital signature of the Certification Authority for insuring the integrity of the digital certificate. One of the reasons for an expiration date is to limit the liability of a Certification Authority due to the likelihood that attributes other than the identity of the public key owner change over time. The most widely accepted format for digital certificates is defined by the CCITT X.509 international standard; thus, certificates can be read or written by any application complying with X.509. Based on a digital certificate included in an EC, a recipient is able to authenticate the digital certificate using a public key of the Certification Authority and thereby, presumably, confirm the identity of the owner set forth therein. The overall system wherein a digital certificate is included in an EC comprises a “public key infrastructure” (PKI), and is referred to herein as the “Certification Authority Digital Signature” or “CADS” system, which is incorporated herein by reference.
A conventional implementation 100 of the CADS system in the context of an electronic transaction between a purchaser 102 and an online merchant 110 is illustrated in FIG. 1. Under this system, a purchaser 102 using, for example, a computer 104 creates a purchase order in the form of an electronic message. The purchaser 102 includes in the message relevant account information of a financial institution 112 from which payment is to be made to the merchant 110. The account information includes, for example, a credit card number and expiration date as well as the name on the card. Software on the purchaser's computer 104 then originates a digital signature for the message using a private key of the purchaser 102 safeguarded in the computer 104. The software also maintains a digital certificate on the computer 104 issued by a Certification Authority 106a. The message, digital signature, and digital certificate then are combined into an EC, and the EC is communicated over the Internet 108 to the merchant 110.
Upon receipt, the merchant 110 authenticates the message using the public key in the digital certificate. If successful, the merchant 110 then authenticates the digital certificate using a public key of the Certification Authority 106a. Successful authentication of the digital certificate may satisfy the merchant 110 that the purchaser—the sender of the EC—is the owner identified in the digital certificate. If the merchant 110 is so satisfied, then the merchant 110 submits the account information to the relevant financial institution 112 for an approval for payment to the merchant 110 from the account. Upon receipt from the financial institution 112 of approval for payment, the merchant 110 fills the purchase order of the purchaser 102. Furthermore, confirmation of approval (or rejection) of the purchase order preferably is sent from the merchant 110 to the purchaser 102.
While the CADS system enables two parties who otherwise may not have a preexisting relationship with one another to communicate with each other with the confidence of knowing the other's identity, the CADS system has significant drawbacks. For example, a digital certificate typically is issued with an expiration date, and an expired digital certificate generally is not recognized in the industry. Furthermore, if a private key is lost or stolen, then the owner of the private key must notify the Certification Authority to revoke the owner's digital certificate; however, a recipient of an EC with a digital certificate will only know of the revocation of the digital certificate if the recipient cross-references the serial number of the digital certificate against a certificate revocation list (CRL) published by the Certification Authority. Another drawback to the CADS system is that the digital certificate itself is only as good as the particular authority that issues it, and it often is necessary to obtain multiple digital certificates (i.e., from Certificate Authorities 106a, 106b to 106n) in order to create a sufficient “chain” or “network” of trust between the purchaser 104 and merchant 110 for a transaction or communication to be accepted and acted upon.
In addition to these drawbacks, a fundamental flaw to the CADS system actually providing a trusted authentication system based upon digital signatures is that a digital certificate only certifies the identity (or other attributes) of the owner of a private key, and falls significantly short of certifying that the private key actually has been used by the legal owner thereof in generating a particular digital signature. Indeed, trust in the CADS system—and generally in any digital signature system—depends upon the legitimate possession and use of the private key, i.e., upon the sender of each particular EC actually being the private key owner. A fraudulent use of a private key to generate a digital signature of an EC currently cannot be detected through the above-described Message Authentication and Factor A Entity Authentication procedures. The digital signature system therefore is susceptible to fraud if a private key of a device is stolen, either by discovery of the private key therein and subsequent copying and use in another device capable of generating digital signatures, or by physical theft of the device containing the private key.
To guard against fraudulent use of a device to generate a digital signature through theft of the device itself, a personal identification number (PIN), password, or passphrase (collectively referred to herein as “Secret”) is typically prestored within the device and must be input into the device before it will operate to generate digital signatures. Alternatively, the Secret is shared with the recipient beforehand and, when the EC later is sent to the recipient, the Secret also is sent to the recipient in association with the message. In the first case, verification of the Secret authenticates the user of the device (herein “User Authentication”), and in the second case, verification of the Secret authenticates the sender of the EC (herein “Sender Authentication”). In either case, confirmation of the Secret represents entity authentication based on Factor B Entity Authentication. Another security aspect that guards against fraudulent use of the device through physical theft include the verification of a biometric characteristic—like a fingerprint—of the user of the device or sender of the EC. This type of authentication is based on Factor C Entity Authentication. As with the Secret, a biometric value is either maintained within the device for User Authentication, or is shared with the recipient beforehand for Sender Authentication by the recipient.
To guard against discovery of a private key and subsequent copying and use in another device, devices are manufactured with electronic shielding, zeroization, auditing, tamper evidence and tamper response, and other security aspects that serve to safeguard the private key (and other protected data) contained therein. Such security aspects of devices include hardware, software, and firmware, and are well known in the art of manufacturing secure computer chips and other devices having cryptographic modules. The requirements of such security aspects are specified, for example, in Federal Information Processing Standards Publication 140-1, Security Requirements for Cryptographic Modules, U.S. DOC/NBS, Jan. 11, 1994 (herein “FIPS PUB 140-1”), which is incorporated herein by reference and which is available for download at http://csrc.nist.gov/publications/fips; and Federal Information Processing Standards Publication 140-2, Security Requirements for Cryptographic Modules, U.S. DOC/NBS, May 25, 2001 (herein “FIPS PUB 140-2”), which is incorporated herein by reference and which is available for download at http://csrc.nist.gov/publications/fips. FIPS PUB 140-1 and 140-2 also define security levels that may be met by a device based on the device's security aspects, with each of these defined security levels generally representing a various level of difficulty—in terms of time and money—that would be encountered in attempting to discern a private key of a device. Currently, four security levels are defined with security level 4 being the highest level of security available. Specifications for such security aspects also are set forth in Trusted Computing Platform Alliance Trusted Platform Module Protection Profile Version 0.45, Trusted Computing Platform Alliance, September 2000; Trusted Platform Module (TPM) Security Policy Version 0.45, Trusted Computing Platform Alliance, October 2000; and TCPA PC Implementations Specification Version 0.95, Trusted Computing Platform Alliance, Jul. 4, 2001, which are incorporated herein by reference (collectively “TCPA Documents”), and which are available for download at http://www.trustedpc.com; and Common Criteria for Information Technology Security Evaluation, Smart Card Protection Profile, Draft Version 2.1d, Smart Card Security User Group, Mar. 21, 2001, which is incorporated herein by reference (hereinafter “Smart Card Protection Profile”), and which is available for download at http://csrc.nist.gov.
As described in more detail herein, the particular aspects of a device that safeguard against discovery of a private key and other protected data are referred to herein as “security characteristics” of the device. The particular aspects of a device that safeguard against unauthorized use of the device by authenticating the user are referred to herein as “authentication capabilities” of the device. The “security aspects” of a device (including a cryptographic module or TPM) comprise the security characteristics and authentication capabilities as well as other security aspects of the device, the requirements of which are specified in the above cited references.
Unfortunately, while the aforementioned security aspects generally reduce overall the risk of fraud within the digital signature system, a recipient of any one particular EC including a digital signature may be unfamiliar with the device used to generate the digital signature and, therefore, be unable to gauge the risk of whether the digital signature was generated fraudulently, either through theft of the device or discovery of the private key.
Of course, if the recipient possesses a shared secret or a biometric value of the sender for performing Sender Authentication, then the recipient may determine that the digital signature was not fraudulently generated assuming that the shared secret or biometric value was not stolen. However, this type of protection by the recipient has significant drawbacks and is not always used by the recipient. For example, if the Secret or biometric value is communicated to the recipient in association with a message for Sender Authentication by the recipient, then the Secret or biometric value first must have been shared with the recipient beforehand and safeguarded by the recipient as part of an established, preexisting relationship; consequently, a recipient having no prior existing relationship with the sender is unable to perform Sender Authentication.
Another drawback is that the sharing of the Secret or biometric value with the recipient exposes the recipient to liability and exposes the Secret or biometric value itself to a greater risk of theft and dissemination. The transmission of the Secret or biometric value for verification carries with it the risk of interception and discovery during transit. Upon receipt, the Secret or biometric value must be safeguarded by the recipient, which inherently gives rise to a risk of theft from the recipient. This is especially significant in the corporate context where a rogue employee may steal the safeguarded Secret or biometric value (insider fraud historically has been the greatest threat). The potential damages also are extensive when the Secret or biometric value is stolen. Since it is difficult for an individual to remember multiple Secrets for multiple recipients, it is common for the same Secret to be used with different recipients. The theft of the Secret from one recipient thereby compromises the Sender Authentication performed by all of the recipients, at least until the Secret is changed for each recipient. In the case of the theft of a biometric value, the damages are even more severe, as a sender's biometric characteristic cannot be changed and, once lost, potentially compromises any future Sender Authentication therewith.
Alternatively, when the Secret or biometric value is prestored and maintained within the device for User Authentication, the risks associated with safeguarding of the Secret or biometric value by the recipient and associated with transmission of the Secret or biometric value to the recipient are avoided. In this conventional paradigm, the recipient does not actually perform the verification—it is done at the device level. A drawback to this alternative paradigm, however, is that because the device remains inoperable until the correct Secret or biometric value of the user is entered, the recipient is unable to monitor repeated attempts to guess the Secret or biometric value. Furthermore, when the device is enabled by the entry of the correct Secret or a biometric value resulting in a match, the device typically remains enabled for a predefined period of time thereafter, such as until it is powered off or resets. Under this alternative paradigm, a recipient is unable to determine whether a particular EC sent during such a time period includes a fraudulently generated digital signature, as the device may have been stolen after being enabled but before its deactivation. Accordingly, while there is User Authentication under this alternative paradigm, there is no provision per se for Sender Authentication.
Yet another drawback is that this alternative paradigm does not particularly accommodate the use of the device to send ECs to different recipients when a biometric value is prestored and maintained within—and Factor C Entity Authentication is performed by—the device. In this regard, different recipients may have different requirements as to what constitutes a biometric “match” so as to be a successful verification; a biometric match is a determination of whether a biometric value input is sufficiently close to a stored biometric value so as to meet at least a minimum security threshold. A security threshold is subjectively set by each recipient and includes factors such as the nature of the communication and the extent of liability to the recipient for actions and responses based on a fraudulently sent EC. Different recipients cannot make their own match/no-match determinations based on their own requirements, standards, and criteria if each recipient does not receive beforehand the biometric value of the sender, make its own comparison thereof with each additional biometric value that is received in association with a message, and apply its own business judgment as to whether the comparison is sufficiently close so as to be a match.
Accordingly, a need exists for a new authentication paradigm for ECs in which Factor B Entity Authentication and/or Factor C Entity Authentication is used, but in which the aforementioned drawbacks of the conventional paradigms that use such authentication techniques are overcome. In particular, a need exists for such a paradigm that provides for both User Authentication as well as for Sender Authentication using either or both of Factor B Entity Authentication and Factor C Entity Authentication, and all without requiring a recipient to safeguard either a Secret or a biometric value. In this regard, a need exists for such a paradigm in which Factor B Entity Authentication and Factor C Entity Authentication can be reliably inferred by the recipient without the recipient being privy to the authenticating information, thereby addressing privacy concerns. Furthermore, a need exists in such a paradigm for the recipient to be able to determine, in its own subjective business judgment, what constitutes a successful biometric match when Factor C Entity Authentication is used. A need also exists for such a paradigm in which the recipient is able to monitor repeated attacks on a device to guess a Secret or a biometric value, and for such an authentication paradigm that further accommodates the use of a single device for the sending of ECs to various, unrelated recipients.
Additionally, a recipient generally is unable to gauge the risk of whether a digital signature was generated fraudulently when no secret or biometric value is shared between the sender and the recipient. Instead, a recipient must rely upon blind trust in accepting that the device used to generate the digital signature has not been stolen and in accepting that the device used to generate the digital signature has sufficient safeguards to protect its private key from discovery, copying, and use in a counterfeit device. A need therefore exists for a method by which a recipient may reliably identify a risk of whether a digital signature has been generated fraudulently using a stolen private key (whether stolen by physical theft of the device or discovery of the private key itself), whereby the recipient may protect itself against fraud. In this regard, a need also exists for a method by which a recipient of an EC including a digital signature may reliably determine at any given time the current level of security of the device to which belongs the private key used to generate the digital signature. A need also exists for a method by which a recipient of an EC may reliably determine an assurance level of the device as well as the specific safeguards of such device that protect against fraudulent use thereof.
Finally, a need also exists for an alternative paradigm in which Factor B and/or Factor C Entity Authentication can be reliably inferred from information provided to a recipient by a device, the reliability of such device also being ascertainable by the recipient.